Distributed transactions are often performed on distributed computing systems. A distributed transaction is a set of operations that update shared objects. Distributed transactions must satisfy the properties of Atomicity, Consistency, Isolation and Durability, known commonly as the ACID properties. According to the Atomicity property, either the transaction successfully executes to completion, and the effects of all operations are recorded, or the transaction fails. The Consistency property requires that the transaction does not violate integrity constraints of the shared objects. The Isolation property requires that intermediate effects of the transaction are not detectable to concurrent transactions. Finally, the Durability property requires that changes to shared objects due to the transaction are permanent.
To ensure the Atomicity property, all participants of the distributed transaction must coordinate their actions so that they either unanimously abort or unanimously commit to the transaction. A two-phase commit protocol is commonly used to ensure Atomicity. Under the two-phase commit protocol, the distributed system performs the commit operation in two phases. In the first phase, commonly known as the prepare phase or request phase, a coordinator node (a node in the distributed computing system managing the transaction) asks all participant nodes whether they are willing to commit to the transaction. During the second phase, commonly known as the commit phase, the coordinator node determines whether the transaction should be completed. If during the prepare phase all participant nodes committed to the transaction, the coordinator node successfully completes the transaction. If during the prepare phase one or more participant nodes failed to commit to the transaction, the coordinator node does not complete the transaction.
The two-phase commit protocol, although widely used, introduces substantial delay in transaction processing. To reduce this delay, some conventional distributed systems have implemented a read-only optimization to the two-phase commit protocol. Using the read-only optimization, a participant node can respond during the prepare phase with a read-only response. The read-only response notifies the coordinator node that the sender of the read-only response will not undergo a state change due to the transaction. Therefore, it does not matter to that participant node whether or not the transaction is successful. The read-only response causes that participant node to be dropped out of the transaction. However, even if all participant nodes return a read-only response, the coordinator continues the two-phase commit protocol, and initiates the commit phase once responses are received from all participant nodes.
Other conventional distributed systems have implemented a one-phase commit optimization. Under the conventional one-phase commit optimization, if there is only a single node participating in a transaction, the prepare phase is skipped. However, the one-phase commit optimization is limited to transactions having a single participant.